這篇要從一句很短的話開始。

它出現在我的專案筆記裡,講的是已經抓下來的那批資料:

「已挖到的資料在 onboarding-kb(5 個 md,先不要全讀,需要時再查)」

而在同一個地方,還跟著一句註解:

「這句很重要,不然可能一次把 75KB 全吃進去,又回到原點。」

我原本打算把這篇寫成「我踩過什麼坑才學會這句話」。

但我回頭看的時候,發現一件事:我不確定這句話是我寫的。

很可能是它提醒我的

老實說,我覺得那句話比較像是它講的,不是我講的。

在那種一邊做一邊記的協作裡,筆記是兩個人一起長出來的。我丟一段指令、它整理一段結論,然後那些東西混在同一份檔案裡。三天之後回頭看,分不清哪一句是誰說的。

我想了一下要不要把這件事寫出來,因為它有點削弱這篇的正當性——如果連這個關鍵的規則都不是我想出來的,那我在講什麼?

但後來我決定寫,理由有兩個。

第一,這就是真實的樣子。 我不想假裝這個專案裡的每一個好決定都是我的靈光一閃。有些不是。

第二,更重要的——誰說的,其實不影響這句話對不對。

而我確實是後來才懂它為什麼對的。

我覺得這兩件事的差別很重要:接受一條規則,和理解一條規則,是兩回事。 我一開始只是照做,後來才知道它擋掉了什麼。

那今天要講的,就是我後來理解的那部分。

理由一:額度會爆掉

這條最直接,昨天整篇都在講。

75KB 一次吃進去,額度就是那樣沒了。而 Day 15 講過,我的額度是跟本業搶來的——這一次全讀,代價是我下午查不了卡片。

這個理由很好懂,但它其實是比較不重要的那一個。

因為如果只有這個理由,那結論會是「等額度多一點再全讀」。

而真正的理由是:就算額度無限,也不該全讀。

理由二:餵太多,它會變笨

這條就不直覺了,而且它是我後來才真的相信的。

一次丟進去的東西超過它能一次握住的量之後,會發生一件事:中間的部分會被壓縮、被摘要、被丟掉。

而關鍵在於——被丟掉的那部分,不會跟你說一聲。

它不會停下來說「等一下,你給我的東西太多了,我只記得前面三分之一」。它會繼續往下寫,而且寫出來的東西一樣通順、一樣有自信。

Day 10 我留過一個沒有解決的疑問:那些放錯位置的答案,到底是「資料裡沒有」,還是「資料裡有但它已經忘了」?我說我沒有辦法從結果反推。

而這條規則,不需要我反推。 它直接把第二種可能排除掉——不要一次餵超過它握得住的量,那第二種失敗就不會發生。

那句註解裡的「又回到原點」,指的就是這個原點:

回到那個我一次丟一大包、然後得到一份讀起來完美但錯位的文件的狀態。

所以這句話其實不是省錢技巧

這是我後來覺得最有意思的地方。

「先不要全讀」聽起來像一個節省資源的小訣竅,跟「記得關燈」差不多等級。

但它其實是一個架構決策,而且是那種會往下決定一大堆事情的。

推導一次:

1. 如果查詢的時候不能全讀
2. 那就必須只讀相關的那一部分
3. 要能只讀相關的部分,就得事先知道哪些是相關的
4. 要能事先知道,資料就必須先被切開、被標記、被索引
5. 而這些工作,只能在建置的時候做——因為查詢的當下已經沒有額度了

第 5 步是整個專案的分水嶺:

我沒有辦法讓它在回答的時候變聰明,所以我只能在它回答之前,把東西整理到夠好。

這句話決定了後面所有的工程。

推理要在建置期做完;查詢的時候,它只需要把現成的東西講成人話。

(這條線怎麼真的長出一整條管線,是後面幾天的題目。)

一個附帶的好處:它逼我先想清楚要問什麼

還有一個我沒有預期到的效果。

「需要時再查」這四個字,隱含了一個要求:你得先知道你要查什麼。

而在此之前,我的習慣其實是相反的——先把資料都準備好,再開始想問題。 那個做法感覺很安全:反正東西都在手上了。

但它其實是在逃避一件事:我還不知道我要問什麼。

一旦變成「需要時再查」,我就被逼著先把問題講清楚。而把問題講清楚這件事,往往比查資料本身還有價值——Day 11 那五個追問,本質上就是同一件事。

資料在手邊,會讓人以為自己準備好了。

那這條規則有沒有代價?

有,而且我得誠實講。

「需要時再查」的前提是查得到。

如果索引切得不好、關鍵字對不上,那需要的東西就是撈不出來。而這種失敗長得很像「資料裡沒有」——你會以為那件事沒被記錄,其實只是你沒找到。

所以這條規則真正的成本,不在於它限制了什麼,而在於:它把壓力全部轉移到了「切得好不好」這件事上。

全讀是笨,但它至少是安全的笨——東西都在那裡。

而「需要時再查」是聰明的做法,但它必須做對才有價值。

這也是為什麼我後來花了那麼多力氣在切塊跟索引上面。那不是在做優化,那是在補這條規則欠下的債。

明天:三條路,以及為什麼我連考慮都沒認真考慮過其中一條

Phase 3 到這裡結束了。這幾天講的都是邊界:什麼不給、放在哪裡、給多少、一次給多少。

而從明天開始要講的是,有了這些邊界之後,東西到底怎麼做出來。

第一個問題就是最根本的那個:要用什麼方式,讓一個模型懂我們公司的事?

有三條常見的路。我選了其中一條,而另外一條——我後來發現,我從頭到尾沒有真的把它當成選項。